<?php
/**
 * <https://y.st./>
 * Copyright © 2016 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'title' => "I swear, I hate the $a[WHATWG].",
	'body' => <<<END
<p>
	While trying to research what to do about computing table cell widths for <a href="https://git.vola7ileiax4ueow.onion/y.st./include.d">include.d</a>&apos;s $a[XHTML]-to-plain-text conversion class, I ran across information hinting that the $a[WHATWG] has a presence on <a href="ircs://sbuk7aqcxkoyipwv.onion:49152/%23WHATWG">freenode</a>.
	I&apos;ve never been a fan of the $a[WHATWG], as they tried to overthrow the $a[W3C] as the standards-setter for $a[XHTML]/$a[HTML] (and mostly succeeded in doing so).
	They revived $a[HTML], which should be dead, and killed $a[XHTML]2, which should have been our new standard.
	$a[HTML] is messy and $a[XHTML]2 cleaned up most, if not all, of that mess.
	However, with the $a[WHATWG] being pretty much the people in charge now, and seeing as they are trying to get markup rendered similarly across all Web clients, I figured that I should pocket my disdain for the time being, pay them a visit, and ask for their advice.
	Avoiding their help doesn&apos;t undo the past and getting their help, provided I still follow the $a[W3C]&apos;s version of $a[XHTML]5 instead of the $a[WHATWG]&apos;s, doesn&apos;t further any bad parts of the $a[WHATWG]&apos;s agenda.
	Of course, freenode was being a pain as usual, so I wasn&apos;t able to connect right away.
	Trying to speed the process, I went to the $a[WHATWG]&apos;s website to see if this presence on freenode was official and if they also had a presence on other $a[IRC] networks.
	What I found there shocked me.
	In several places, it&apos;s mentioned that the $a[WHATWG] is opposed to the $a[W3C]&apos;s finalized version of the specification.
	They are against there being any stable standard, instead insisting that a &quot;living standard&quot; is the way to go.
	With a so-called &quot;living standard&quot;, there is no way to be sure that a document is valid, as the definition of &quot;valid&quot; constantly changes.
	There&apos;s no way to measure compatibility.
	You can&apos;t say that Web client X is compatible with $a[XHTML] version Y, because there is no version Y, or any other version number.
	Worse still though is what this message tells us about the $a[WHATWG].
	For example, take the <a href="https://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_HTML_spec.3F">following passage</a>:
</p>
<blockquote><p>
	The W3C publishes some forked versions of these specifications.
	We have requested that they stop publishing these but they have refused.
	They copy most of our fixes into their forks, but their forks are usually weeks to months behind.
	They also make intentional changes, and sometimes even unintentional changes, to their versions.
	We highly recommend not paying any attention to the W3C forks of WHATWG standards.
</p></blockquote>
<p>
	<q>We highly recommend not paying any attention to the W3C forks of WHATWG standards.</q> They dismiss the $a[W3C], recommending that people not pay attention to them.
	It doesn&apos;t matter to the $a[WHATWG] that they&apos;ve effectively taken over $a[XHTML]/$a[HTML], with the $a[W3C] mostly only giving stability to the $a[WHATWG]&apos;s standard.
	They want the $a[W3C] to keep their hands out of $a[XHTML]/$a[HTML] altogether!
</p>
<p>
	The line above that passage is even more horrifying though.
	<q>The WHATWG also works on other standards, such as the DOM, URL, and XMLHttpRequest standards.</q> I don&apos;t know if the Document Object Model has any context outside the Web and XMLHttpRequest clearly has something to do with $a[HTTP] (in other words, the Web).
	The $a[WHATWG] is trying to redefine $a[URL]s though! What gall! $a[URL]s are the largest subgroup of $a[URI].
	$a[URI]s span more than just use on the Web, and for them to be effective, they need a single, unified syntax, <strong>*not*</strong> one that&apos;s Web-specific.
	Furthermore, the <a href="https://url.spec.whatwg.org/">$a[WHATWG]&apos;s strange $a[URL] specification</a> is more difficult to understand than <a href="https://tools.ietf.org./html/rfc3986">$a[RFC] 3986</a> and includes platform-specific nonsense such as Windows drive letters! $a[URI]s, including $a[URL]s, are not platform-specific and shouldn&apos;t include features that require parsing based on platform-specific operating system features.
	To be clear, their definition doesn&apos;t seem to require normalization in a platform-specific way, so $a[URI]s would still parse the same way on every platform, but all platforms would need to watch for syntax specific to other platforms when parsing, which is almost as bad.
	Perhaps I&apos;d be less against the $a[WHATWG] redefining $a[URI]s if the $a[WHATWG] was a more competent group, but instead of sustainability, future compatibility, and document cleanliness, their main concern seems to be to codify what incorrect behavior Web clients currently exhibit and define a new &quot;correct&quot; based on that strange behavior.
	If the $a[WHATWG] was actually a competent group, their $a[URL] definition could be better than the $a[IETF]&apos;s definition simply because the $a[IETF]&apos;s definition is nonfree.
	However, the $a[WHATWG] was formed out of a perceived need to fight the cleaning of the $a[HTML] language, so it makes sense that they aren&apos;t defining reasonable standards.
</p>
<p>
	In case anyone&apos;s curious, yes, the $a[WHATWG]&apos;s only official $a[IRC] presence did turn out to be on freenode.
</p>
<p>
	I finished all the trivial work on my $a[XHTML]-to-plain-text class, but the thought of dealing with ordered lists and tables was too daunting for today.
	I even got <code>&lt;iframe/&gt;</code>s implemented, though not according to the specification.
	Unfortunately, the specification says that if the <a href="https://www.w3.org./TR/html5/embedded-content-0.html#process-the-iframe-attributes"><code>srcdoc</code> attribute</a> is specified, it represents a nested document with a <code>text/html</code> <code>Content-Type</code>.
	This is regardless of whether the containing document has an <code>application/xhtml+xml</code> <code>Content-Type</code>, clearly indicating that the author intended for the document to be $a[XHTML], not $a[HTML].
	I&apos;m using an $a[XML] parser.
	I can&apos;t make it work on malformed markup such as unclean-yet-valid $a[HTML] code.
	My class isn&apos;t built to work on random pages found on the Web though, it&apos;s built to allow authors to mark up their documents in a real markup language, then present them as plain text files.
	If people plan to make use of such a markup class, they&apos;ll have to use that markup class&apos; unique language.
	The fact that my class&apos; language is identical to $a[XHTML] in all ways besides the handling of <code>&lt;iframe/&gt;</code> <code>srcdoc</code> attribute doesn&apos;t seem overly problematic.
	A real $a[XHTML] author would use $a[XHTML] in that attribute anyway, just making sure that their syntax conformed with the new <a href="https://www.w3.org./TR/html-polyglot/">$a[HTML]5 polyglot syntax</a>, which conforms with both the $a[XHTML]5 rules and the $a[HTML]5 rules.
	That way, they&apos;d have the well-formed-ness of $a[XHTML] but would still be following the specification by using $a[HTML]-compatible markup.
	After finishing with <code>&lt;iframe/&gt;</code>s, I should have completed the work on unordered lists, but it seemed a little too complex for today.
	I instead started looking for solutions to the more complex task of figuring out how to calculate optimal table column widths to minimize table height.
	When you&apos;re faced with a complex task, instead work on an even more complex task.
	Great idea, right⸮ Without any better idea than to calculate the table many times, once to try every possible column width, and choose the shortest table, I didn&apos;t have any idea how to complete the task at hand.
	Reluctantly, I decided to speak with people in #WHATWG, which is when I ran into the information that I found above.
	I&apos;m still probably going to try to solicit their help though, as they might have information on how Web browsers typically deal with the problem of calculating optimal column widths, as they have to do something very similar to what I&apos;m doing.
</p>
<p>
	I continued thinning down my belongings today, though admittedly, spent most of my time instead trying to figure out what to do about <code>&lt;table/&gt;</code>s, so I didn&apos;t get a whole lot thinned down.
	I found my old $a[FSF] membership card, but I&apos;m not sure what to do with it.
	I&apos;m not sure if my membership has technically expired or not, but I certainly haven&apos;t considered myself a member for well over a year.
	The membership card doubles as a $a[USB] drive though, so if I erase Trisquel from it, it could be useful for small data storage.
</p>
<p>
	Vanessa, our mother, and I went out to collect bullet shells for a while, and later, we went out to walk on the dunes.
	After we got home, Cyrus made it home as well.
</p>
END
);
